pre-commit.ci autofix

Hi @Ashutosh0x thanks for the PR, please be aware reviews can be quite slow due to maintainers only being able to volunteer their spare time to pip.

That said, I would like you to explicitly explain the design here:

1. What is the intended priority between index-url,extra-index-url, and --find-links options?
2. Does this match uv's behavior (https://docs.astral.sh/uv/concepts/indexes/#-index-url-and-extra-index-url)?
3. When multiple links are specified for find-links and multiple index urls expecified for extra-index-url what is the intended priority direction?
4. Is there a specific index-strategy from uv this matches (https://docs.astral.sh/uv/reference/cli/#uv-pip-compile--index-strategy)?

To be clear you don't have to match uv, but given it's set a precedent it should be understood if not why not.

If the design is agreed on there will need to be at least an update to the user guide, as well as unit and functional tests.

I also think I prefer uv's choice of have an option that can take different values, rather than a boolean, this will allow users to explicitly choose new or old behavior, add new options in the future, and potentially change the default.

P.S The Windows failures for Run winget install --accept-source-agreements --accept-package-agreements -e --id Slik.Subversion is unrelated to this PR, I will try and fix it in a different PR when I have time.

Thanks for the review @notatallshaw!

Regarding the design questions:

1. Priority Order: In the current implementation, find-links are always collected first (aggregating all of them, as they are often used for supplementary artifacts). Then, we iterate through --index-url and --extra-index-url sequences in order. We stop searching indexes as soon as one index URL returns candidates. The final candidate list is a combination of everything found in --find-links plus the first successful index.

   • Direction: find-links (all) -> index-url -> extra-index-url (first match stops).

2. UV Comparison: This aims to mimic uv's unsafe-first-match strategy where it respects the order of index definition.

3. Boolean vs Strategy: I completely agree. Migrating to an --index-strategy option (enum) is much more robust and future-proof than a simple boolean. It allows us to support first-match now and potential other strategies later without polluting the namespace.

Plan:
I will update this PR to:

1. Replace --index-priority with --index-strategy.
2. Support values like best-match (default, legacy behavior) and first-match (new isolated behavior).
3. Add proper documentation on how this interacts with find-links.

I'll push these changes shortly!

--index-strategy and --index-mapping seem to be two separate features, they should not be in the same PR, break it out into a separate PR. In the new PR describe the design of your feature so we can evaluate it and the implementation.

Also, for --index-mapping if the request doesn't already exist create one, so there is a place to discuss if this is a worthwhile feature or if there are any important design considerations, and the PR can be focused on the implementation.